Traditional mobility support aims to provide continuous Internet connectivity to mobile hosts, such as for example a laptop computer with wireless connectivity. By contrast, network mobility support is concerned with situations where an entire network comprising potentially many hosts changes its point of attachment to the Internet topology and thus the route to reach it in the topology. Such a network in movement can be called a Mobile Network.
A number of scenarios exist where such Mobile Networks occur. To give just two examples:                i. A Personal Area Network (PAN, i.e. a network of several personal devices attached to an individual) will change its point of attachment to the Internet topology whilst the user is walking around town.        ii. A network embedded in a bus or aircraft providing on-board Internet access to passengers. These passengers may be using a single device (e.g. a laptop) or in turn own a Mobile Network (such as a PAN), which then illustrates the case of a Mobile Network visiting a Mobile Network (i.e. nested mobility).        
A Mobile Network (MONET) can therefore be defined as a set of nodes, part of one or more IP-subnets attached to a Mobile Router (MR), that are mobile as a unit, with respect to the rest of the Internet. In other words, an MR and all its attached nodes (so called Mobile Network Nodes or MNNs).
An MNN itself may be a local fixed node (LFN) permanently associated with a given mobile network, a local mobile node (LMN) capable of altering its point of network attachment within the current mobile network and of leaving the current mobile network to attach elsewhere, or a visiting mobile node (VMN), whose home link is not on the current mobile network and has changed its point of attachment from somewhere outside the current mobile network. As noted above, the MNN can be a simple mobile host or another mobile router, resulting in nested mobility.
With the change of attachment points available to mobile networks, a method of optimising the route by which packets of data are sent and received by such networks is highly desirable for a number of reasons:                i. Route optimisation reduces delay by reducing packet path length;        ii. It increases overall available bandwidth in the system because packets are routed through a shorter path, and are no longer tunnelled;        iii. It can increase the maximum transmission unit size on the communication path, reducing fragmentation of the payload.        
The Mobility Support in the IPv6 (‘mobile IPv6’ or MIPv6) specification (see http://www.ietf.org/) proposes means to enable Route Optimisation (bi-directional communication using the shortest path) between an MN and a correspondent node (CN), but no mechanism has been proposed as yet to enable route optimisation between an MNN and a CN.
Referring to FIG. 1, the basic network mobility support (“NEMO Basic Support Protocol” at http://www.ietf.org/) for communication between an MNN and a CN relies on bi-directional tunnelling between the mobile router (MR) and its home agent (HA):                i. Inbound packets (from a CN to a MNN) are sent to the MR's home link; The MR's HA intercepts and tunnels them to the MR.        ii. Outbound packets (from an MNN to a CN) are reverse-tunnelled by the MR to its HA.        
However, this does not provide route optimisation to the MNN.
EP 1 158 742 A1 and associated paper, “Mobile Networks Support in Mobile IPv6 (Prefix Scope Binding Updates)”, by T. Ernst, A. Olivereau, L. Bellier, C. Castelluccia, H. -Y. Lach, IETF Internet-Draft draft-ernst-mobileip-v6-network-03.txt, March 2002, describe how when an MR roams to a visited network, it sends a modified version of the MIPv6 binding update (BU), referred to by these documents as a prefix scope binding update (PSBU), to its home agent (HA).
The classical MIPv6 BU only informs the CN of where to send data addressed to a single mobile node (e.g. the mobile routers home address (HoA) coupled to a roving care-of address (CoA)). The proposed PSBU does not bind an MR HoA to an MR CoA but the MR prefix to the MR CoA, thus informing the HA receiving the PSBU to send data addressed to any MNN attached to the MR on to the MR CoA.
Upon reception of a packet whose destination address matches with the MR prefix (e.g. the destination is an MNN), the Home Agent (HA) must then tunnel the packet to the MR CoA that will deliver it to the actual recipient.
Similarly the MR may send PSBUs to the correspondent nodes of the MNNs, which would achieve CN/MNN route optimisation.
However, this solution is only acceptable if the PSBU can be successfully validated by its recipient. Beyond peer authentication, the PSBU sender has to actually prove that it owns the whole prefix that it sends a PSBU for.
This is not a problem as long as the recipient of the PSBU is the MR Home Agent, which is expected to have initial knowledge about the prefix that belongs to the MR. However when the recipient is any CN, a mechanism has to be found to allow that CN to validate a PSBU. No mechanism has been proposed as yet, which greatly reduces the applicability of this solution.
One may consider the applicability of the methods already proposed for classic MIPv6 BU validation:
i. Cryptographically Generated Addresses.
In this solution, a home address (HoA) is bound to a public key that is part of a public/private key pair. This ensures that a malicious node cannot assume the mantle of the home address, as it does not own the corresponding private key.
In reference to PSBU, however, this method cannot be extended to prefix ownership as a large number of home addresses may share the same prefix. Moreover it is unlikely that MIPv6 or any future specification is going to allow any mobile network to assign its own address or prefix. Adding an additional hash to the prefix in order to make the ownership unique, is limited by the available number of bits in the network prefix. Estimates suggest that only 216 (approximately 65,000) public keys would need to be tested by an attacker to achieve a 50% chance of losing uniqueness and thus security.
ii. Return Routability Checking Procedure (RRP). RRPs are now incorporated within the MIPv6 specification, and consist of a check by the correspondent node (CN) to verify that the specified home address (HoA) can actually be reached at the specified care-of address (CoA), before accepting the binding update (BU). Essentially, the process comprises:                A mobile node (MN) initiating the procedure by sending Home Test Initiation (HoTI) and Care-of Test Initiation (COTI) messages to the CN;        The CN sending a Home Test (HoT) message to the home address of the MN and a Care-of Test (CoT) message to the care-of address of the MN;        From the contents of both the HoT and the CoT, The MN generates a key that it uses to sign the BU it is to send.        The MN thus needs to successfully receive both the HoT and the CoT to be able to generate a valid BU. This is considered by the CN as a sufficient proof that the home and care-of addresses are valid for that MN.        In reference to PSBU, however, this mechanism cannot be used to ensure that a whole prefix can be reached at a certain care-of address. Prefix ownership is much more than address ownership: to obtain a similar level of security, it would be necessary for the CN to check using RRP all possible addresses that can be derived from that network prefix.        This is clearly unacceptable, as standard prefix lengths lead to an enormous quantity of possible IPv6 addresses.        
Consequently one concludes that PSBU cannot provide validated route optimisation to the mobile network, i.e. it cannot provide validated route optimisation to any mobile network node attached therein.
Thus a need still exists for a method of validated route optimisation for mobile network nodes.
The purpose of the present invention is to address the above need.